enable network on ipv6-only hosts #208
Conversation
The networkd template explicitly disables IPv6-connectivity. When connecting to a host, the attempt to use IPv6 results in -ENETUNREACH from the guest kernel. If the host is IPv6-only, the host kernel likewise makes attempts to use IPv4 result in -ENETUNREACH. Hence fakemachine has dysfunctional network when invoked on an IPv6-only host. Closes: go-debos#207 Signed-off-by: Helmut Grohne <[email protected]>
| @@ -301,9 +301,6 @@ Type=ether | |||
|
|
|||
| [Network] | |||
| DHCP=ipv4 | |||
| # Disable link-local address to speedup boot | |||
There was a problem hiding this comment.
Does this cause any slow-down as per the comment above ?
There was a problem hiding this comment.
It quite definitely causes a slow-down. Not sure how much. To me the question is more of whether it works at all. I cannot use debos at all as a result of this problem.
There was a problem hiding this comment.
Sorry for the late reply - I've been too busy to do any debos maintainance. Can you check if adding MaxAttempts=10 (with the original LinkLocalAddressing=no) and possibly IPv6AcceptRA=yes works for ipv6-only host & for regular host ?
There was a problem hiding this comment.
LinkLocal=no with IPv6AcceptRA seems wrong; Just doing ipv6 link local addressing would make more sense;
Mind ofcourse this change was done in 2017 so things in systemd might have changed quite a bit. In particular the behaviour of networkd-wait-online could well have changed to not wait for all address families (which i think was the reason for the slowdown)
@helmutg when you say definitely a slowdown; Is that something that you actually noticed during usage or more an expectation :)
There was a problem hiding this comment.
Sorry for the delay.
I cannot actually observe any delay with these settings, because fakemachine does not actually work in any way unless I change them. It is only that I expect a slowdown.
So I did some more testing. With both IPv6AcceptRA=yes and LinkLocalAddressing=yes, it works most of the time. I had at least one failure and suspect that fakemachine.service was being run before the network interface succeeded in configuring. Just setting MaxAttempts=10 does not improve the situation in any way.
Adding MaxAttempts=10 and IPv6AcceptRA=yes also does not work. Neither IPv6AccptRA=yes nor LinkLocalAddressing=yes make it work in isolation. It is only when we combine them that it starts to work. Without the former, we don't get a default route and without the latter we don't get an IPv6 address assigned that could be routed.
In all of this, when I say "does not work", what I mean is "Network is unreachable" being part of the error message.
Given further debugging, I think this is not the full solution. Network interfaces are not reliably configured when systemd-networkd.service is started. What is really needed here is network-online.target, but that's not WantedBy or Before fakemachine.service in any way. Of course adding network-online.target will make things even slower (again not measured in any way, just an expectation that adding more dependencies will take longer). But then in the context I am trying to use it, it currently does not work at all (due to not supplying any working IPv4 connectivity).
Just because systemd-networkd has been started does not mean it has configured any interfaces (even when they are static). The subsequent unit systemd-network-wait-online.service will wait for at least one interface to be configured (and in fakemachine, there is only one). This is being ordered before network-online.target. Signed-off-by: Helmut Grohne <[email protected]>
The networkd template explicitly disables IPv6-connectivity. When connecting to a host, the attempt to use IPv6 results in -ENETUNREACH from the guest kernel. If the host is IPv6-only, the host kernel likewise makes attempts to use IPv4 result in -ENETUNREACH. Hence fakemachine has dysfunctional network when invoked on an IPv6-only host.
Closes: #207